home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19961006-19970104 / 000371_news@columbia.edu _Fri Dec 27 18:47:06 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.8.3/8.8.3) with ESMTP id SAA26728 for <kermit.misc@watsun.cc.columbia.edu>; Fri, 27 Dec 1996 18:47:06 -0500 (EST)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.8.3/8.8.3) id SAA17874 for kermit.misc@watsun; Fri, 27 Dec 1996 18:47:05 -0500 (EST)
  4. Path: news.columbia.edu!panix!news-xfer.netaxs.com!news.voicenet.com!omni2!cmosley
  5. From: cmosley@voicenet.com (Christopher Mosley)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Not really a kermit question
  8. Date: 27 Dec 1996 23:37:53 GMT
  9. Organization: Voicenet - Internet Access - (215)674-9290
  10. Lines: 107
  11. Message-ID: <5a1mkh$7uv@news1.voicenet.com>
  12. References: <5a119e$c6f@news1.voicenet.com> <5a15md$8gs$1@apakabar.cc.columbia.edu>
  13. NNTP-Posting-Host: omni2.voicenet.com
  14. X-Newsreader: TIN [version 1.2 PL2]
  15. Xref: news.columbia.edu comp.protocols.kermit.misc:6329
  16.  
  17. Frank da Cruz (fdc@watsun.cc.columbia.edu) wrote:
  18. : In article <5a119e$c6f@news1.voicenet.com>,
  19. : Christopher Mosley <cmosley@voicenet.com> wrote:
  20. : : I noticed that I had poor throughput during most of my sessions.
  21. : : I tested this using mskermit and ckermit by using up/downloads during
  22. : : serial dialin sessions. This is what I discovered:
  23. : : 
  24. : :  28.8 connection 115200 modem speed, windows 5, packet size 5000,
  25. : :  42.bis compression,rts/cts. 
  26. : : 
  27. : As you might know, you can also squeeze another 20-25% throughput when
  28. : transferring binary and/or precompressed files by using control-character
  29. : prefixing (available in C-Kermit 5A(189) or later, MS-DOS Kermit 3.13 or
  30. : later -- the current versions are 6.0.192 and 3.14, respectively).
  31.  
  32. : :  1. A session fell into one of two categories either a throughput of
  33. : :  3500 - 3900 cps or 6000 - 6500 cps for a text file (always the same file).
  34. : :  The througput for a precompessed file was always ~3200 cps - this
  35. : :  to assure that that varying line conditions did not account for the
  36. : :  disparity. ~3200 was also the rate for a non-compressed session for
  37. : :  any kind of file. During any one dial in session the cps did not change 
  38. : :  from the slower realm to the faster or faster to slower.
  39. : :  
  40. : OK, so 3200 cps for a precompressed file, always.  That indicates, roughly,
  41. : the actual capacity of the connection.  This is almost exactly what is
  42. : expected (2880 cps / 8-bits-per-character = 3600 cps less about 11% LAPM
  43. : (V.42) overhead = 3204 cps).   And the constancy of this figure rules out
  44. : modulation downshifting of the V.34 connection.  So far so good.
  45.  
  46. : Now a text file is usually quite compressible.  The degree to which it
  47. : is compressed prior to transfer, then, all else being equal (and it seems
  48. : to be) determines the throughput.
  49.  
  50. : If sometimes the file transfers at 3500-3900 cps, and others at 6000-6500,
  51. : this indicates that the the modems have successfuly negotiated a compression
  52. : protocol in the latter case, but not in the former.  This can be verified
  53. : by setting your modem to display its active protocols when it gives its
  54. : CONNECT message, or by escaping back to the modem after connection and giving
  55. : the appropriate command for displaying protocols.
  56.  
  57. : :  2. Varing packet-lengths had no effect other than to slow or speed
  58. : :  up everythimg by the expected amount.
  59. : : 
  60. : :  3.These results were basicly the same at all times: the likelyhood   
  61. : :  of having a good or bad session was the same,  1 out of every 5 
  62. : :  sessions was 'a good one'. This was during times of heavy or light
  63. : :  load on the remote. It was possible to have a good session at times
  64. : :  when the load on the remote was the heaviest and to have a bad
  65. : :  session when the the lightest.
  66. : : 
  67. : :  4. The results were about the same for mnp compression.
  68. : : 
  69. : :  What I wonder.
  70. : : 
  71. : :  1.It seems that compression is occuring, but what is this 
  72. : :  partial compression! ;-( , 3800cps for a file a file that would
  73. : :  have a transfer rate of only slightly less (3200 cps)
  74. : :  when a compression free connection was made?
  75. : :      
  76. : That's because Kermit protocol includes its own form of compression that
  77. : is independent of the modem's.
  78.  
  79. : : The reason I am posting here is the responses/suggestions I have gotten are:
  80. : : 
  81. : :   Don't use kermit. ?
  82. : :
  83. : Thanks for not listening to that one.  I think if you ran the same
  84. : experiments with ZMODEM (which is, no doubt, what these people would tell
  85. : you to use), you would get the same results for precompressed files, but you
  86. : would probably get only the expected 3200 cps for text files, rather than
  87. : the higher throughput that you got with Kermit.  That's assuming the clean
  88. : and totally transparent kind of connection that is required for ZMODEM to
  89. : work well, or at all.
  90.  
  91. : :   Shouldn't use packet lengths of over 1024 on a hayes compatible modems. ?  
  92. : : 
  93. : That doesn't make any sense.  It's not the brand name or command set of the
  94. : modem that's important, but rather its buffering and flow-control capacity.
  95. : In general, the improvement from packet lengths over 1000 is marginal, but
  96. : sometimes (almost in defiance of the underlying math) it can be significant.
  97. : More often, a larger window size is more beneficial.  In all cases, of
  98. : course, you can also improve throughput by "unprefixing" those control
  99. : characters that are safe to send bare.
  100.  
  101. : Kermit performance is discussed and analyzed in depth, with particular
  102. : reference to V.34 connections, in Chapter 12 of the new second edition of
  103. : "Using C-Kermit":
  104.  
  105. :   http://www.columbia.edu/kermit/ck60manual.html
  106.  
  107. : - Frank
  108.  
  109.  Yes, this must be it, the kermit repeat compression of a text file is in
  110.  line with the difference between 3800 cps & 3200 cps. What threw me off was
  111.  that my modem does report V42bis at connect. I assumed kermit's repeat
  112.  compression was taking place but only accounted for some of the difference
  113.  of 600 cps. I suppose since there is no way of turning off kermits repeat
  114.  compression I could use a text file that has no repeats but could still
  115.  be compressed by 42.bis.
  116.  
  117.     But No, 42.bis is either on or off. Some modem/s is/are not telling
  118.  me the truth.
  119.                                                
  120.                                                         Thanks
  121.                                                         cmosley 
  122.       
  123.